昨天寫到，issue 要有可以檢查的驗收條件。實際執行後，我很快就碰到另一個問題：有時不是我不會寫驗收條件，而是我自己還沒想清楚要做什麼。

我平常提出新需求時，常從一句很短的話開始。例如「我想做一個可以追蹤 agent 工作的東西」或「幫我把開發流程串起來」。這些話可以用來開始討論，卻還不能直接拿去寫程式。

以前我把這種想法丟給 agent，它通常會先補齊自己認為合理的細節，接著列出做法，然後問我是否開始。很多時候我看方案大致合理就同意了。做到一半才發現，我和 agent 對「完成」的理解根本不同。

2026 年 8 月，我在做 closed-loop-dev 這個流程時，決定把討論階段固定下來。當時的工作記在 cyclone-agent-config issue #201，目標是讓一個還很模糊的專案想法，先經過詢問和規格整理，再進入實作。

一次只問一題

這個流程開始後，agent 不能看到需求就直接改檔案。它必須先問問題，而且一次只問一題。我回答完，它才能依答案決定下一題。

常見的問題包括：這個東西不做會有什麼影響？做完後我要看到什麼？如果只能先完成一小部分，哪一段最有用？哪些事情這次明確不處理？

一次只問一題對我很重要。一次收到十幾題時，我很容易快速回答前幾題，後面直接用「照建議」帶過。分開問以後，我比較容易發現自己其實沒有答案。

答不出來不代表需求不能做。它只表示這個地方還需要選擇。例如，我說想追蹤 agent 的工作，後來才分清楚至少有兩種東西：一種是跨好幾天、需要交接的長期任務；另一種是某個 agent 在這次 session 正在執行的動作。兩者如果混在同一個狀態裡，後面很容易互相卡住。

這種差異如果在寫程式後才發現，通常要重改資料結構和操作流程。在討論時發現，只要把規格改清楚即可。

問完後要留下一份規格

問題問完後，我不希望只留下聊天紀錄。聊天很長，也很難在幾天後快速確認當時決定了什麼。所以 agent 需要把結果整理成一份規格，內容包括目標、範圍、非目標、驗收條件、風險，以及準備怎麼驗證。

這份規格先不放程式碼。因為一開始討論實作細節，我的注意力很容易跟著 agent 進入「這段 code 怎麼寫」，反而忘了確認功能本身是否符合需求。

規格確認後就凍結。這裡的凍結不是永遠不能改，而是之後如果要改方向，必須明確寫出哪個前提改變了，不能一邊施工一邊偷偷換掉完成標準。

凍結後才建立 GitHub issue。計畫和內容準確的 issue 就代表可以開始，不需要 agent 每做一步又回來問我「是否繼續」。真的碰到安全問題、規格和事實衝突，或已經嘗試多次仍無法通過，才停下來重新討論。

我另外做了一個基本檢查

為了避免規格看起來完整，實際上還留著空白，我替這個流程做了 check_plan.py。它會檢查必要段落是否存在、驗收條件是不是空的、是否還有 TODO 或 TBD，以及有沒有寫出測試方式。

這支檢查器只能處理格式明確的問題。它無法判斷需求是不是好主意，也無法替我決定產品方向。它的用途是擋住「欄位看起來都有，但內容還沒寫完」的計畫。

這套流程後來透過 PR #202 加進我的 agent 設定，測試十五項通過，再由另一個 agent review。它沒有讓我每次都一次想對，但至少讓「還沒想清楚」發生在開始改程式以前。

明天

明天會拿一張實際 issue 來看：驗收清單、PR 和測試結果要怎麼連在一起，讓完成狀態不只是一個勾勾。